Software development is a significant component of both the cost and schedule of the development of unmanned air vehicle systems. Three types of software are required to implement and validate an Unmanned Autonomous Vehicle (UAV) program: the Operational Flight Program (OFP), the Closed Loop Simulation (CLS) and the Test Environment. Unfortunately, very little software is reused from one UAV program to the next. Not only is the OFP often redeveloped from scratch, but also the CLS environment and the software testing environments are all “reinvented” on a program-by-program basis resulting in little consistency, lower quality, and higher costs.
OFP development strategy traditionally aims toward the implementation of a single instance of a large executable program that resides in a specific single target computer using cross-compilation tools. This preconception unnecessarily results in artificial obstacles in the software development process, such as the prerequisite delivery of specialized hardware and/or development tools before any practical software testing can be performed, with the additional possibility that undesirable and undetectable system timing dependencies may be embedded in OFP source code.
The current method for developing flight software places constraints on the software developers by requiring them to develop pieces of the OFP code from scratch on their desktop and then wait until the flight computers are ready on a hot bench before they can do verification and validation. Traditionally, the hot bench becomes a choke point for the schedule as many developers all vie for access to this precious resource. This requires a substantial investment in a hot bench, with a flight computer for each instance of the OFP. This in turn leads to schedule delays, cost overruns, and a lesser quality product as typically two shifts are run.
There is a need for a system for developing software more efficiently.